Project Name

Product Delivery

Test Management Plan

Synopsis:	This plan describes the quality assurance procedures and activities to be carried out for ensuring the successful delivery of the Release/Project.

This is intended to be a ‘living’ document. This Quality Strategy is based on information that is currently available.

Document Status:

Approval:

Author:

Version:

Date:

Table of Contents:

1	Introduction	3

1.1	Distribution list	3

1.2	Document history	3

1.3	Reference documents	3

1.4	Outstanding issues	3

1.5	Purpose of Document	3

2	Project information	3

2.1	Project Scope	3

2.2	Associated Projects and Dependencies	3

2.3	Assumptions	3

2.4	Risks and Issues	3

2.5	Requirement Reviews	3

3	Test Activities	3

3.1	Test Objectives	3

3.2	Test Phases	3

3.3	Overall Test Approach/Strategy	3

3.4	Development Testing	3

3.4.1	Unit Testing	3

3.5	Functional Testing	3

3.5.1	SIT/Feature Testing	3

3.5.2	Regression Testing	3

3.5.3	Installation and Rollback Testing	3

3.5.4	Client/UAT Testing	3

3.6	Non-Functional Testing	3

3.6.1	Data Validation	3

3.6.2	Performance Testing	3

3.7	Documentation	3

3.8	Operations Acceptance Testing (OAT)	3

3.9	UAT (User Acceptance Testing)	3

4	Test Environments	3

4.1	Environment Owners	3

4.2	Environmental Variances	3

5	Reporting	3

5.1	Quality Reports	3

5.2	Defect reports	3

5.3	Weekly QA Meetings	3

5.4	Weekly Project Meetings	3

6	Go Live Criteria	3

6.1	Functional Sign Off	3

6.2	Test Execution & Defect Review	3

6.3	Non Functional Sign Off	3

6.4	Risks and Deficiency Management	3

6.5	Documentation	3

6.6	Installation and Rollback	3

7	Appendix 1 - Staff Requirements	3

7.1	QA Team	3

Introduction

Distribution list

Name	Role	Location

Document history

Version	Date	Author	Changes

Reference documents

Documents will be stored on the SharePoint.

The latest versions stored on (SharePoint link) are regarded as the definitive documents. Other versions or copies held in other repositories should be regarded as potentially superseded.

Document	Description	Location
PIA	Project Implementation Architecture
BRD	High-level business requirements for the project/release as a whole,
Project Schedule & Dependencies	PDM document of deliveries, dependencies, etc.
QA Management Plan	[This document]
Functional Requirements	Detailed functional requirements for the project/release.
Configuration
Performance requirements
Other

Outstanding issues

Reference#	Issue

Purpose of Document

Project information

Project Scope

Describe the project scope.

Associated Projects and Dependencies

Any external or internal dependencies will be outlined in the Release/Project schedule document on SharePoint, maintained by the Proposition Delivery Manager(PDM)/Release Manager(RM).

Assumptions

List any assumptions that might be applicable to the project.

Risks and Issues

The table below contains a subset of risks and issues which relate specifically to testing.

Context	Risks	Level	Impact	Owner	Mitigation

Requirement Reviews

FNFG’s Product and test requirements will be stored in the TMT and/or SharePoint and will be reviewed and approved by the Development, QA and Product/Business Teams.

Functional Area	Reviewer	Date Completed

Test Activities

Test Objectives

Describe the objective of testing activities.

Test Phases

#	Phase	Objective	Owner
Unit	To ensure that the individual components, interfaces and configuration of the system function in isolation. Development group will be responsible for their own unit testing.	Accountable: Responsible:
System / Feature	To ensure that all components of the system function as expected.	Accountable: Responsible:
Regression	To ensure that pre-existing functionality continues to function correctly. Regression testing will be used to verify functionality whenever new releases are made.	Accountable: Responsible:
Installation/Configuration	To ensure that the installation/Configuration process is documented, accurate and repeatable; and that the new release does not impact any shared resources.	Accountable: Responsible:
Data Quality	To validate that data required for the solution is complete, accurate and delivered in a timely manner	Accountable: Responsible:
Performance	To ensure that system performance is not degraded and measure results against 2012 KPIs as per the Performance requirements.	Accountable: Responsible:
Documentation	To review all the project documentation and ensure it meets the needs of its target audience	Accountable: Responsible:
OAT	To ensure the system will function in a production environment. To ensure that alerts are generated and managed correctly.	Accountable: Responsible:

Overall Test Approach/Strategy

#	Objective	Primary Phases
Achieve optimum test coverage in the time available	ALL
Establish a high level of confidence in the product as early as possible in the software development lifecycle.	ALL
Verify the business and functional requirements have been developed according to specification.	ALL
Mitigate the level of business risk associated with implementing new software.	ALL
Continue to improve, optimise and innovate the test process as the release/project evolves.	ALL
Identify test-related risks and issues providing appropriate recommendations.	ALL
To ensure that the system can operate at optimum levels under the predicted business volumes.	Performance (if applicable)

Development Testing

Unit Testing

Attribute	Description
Objectives	To ensure that the components of each part of the solution work in isolation or when run against test harnesses. To ensure that code/configuration is peer reviewed.
Environment
Stage Entry Criteria	Signed off Business Requirement documentation. Reviewed and updated Functional Specifications. Common understanding of requirements across Development, Product/Business and QA Teams.
Stage Exit Criteria	Development of a comprehensive suite of test cases. Successful execution of all tests added specifically for this project/release. Peer reviews conducted where appropriate. Unit Test Summary reports produced.
Deliverables	Unit test report.
Schedule
Responsibilities	Test design, development and execution - Development team.

Functional Testing

SIT/Feature Testing

Attribute	Description
Approach	Newly developed functionality will formally enter QA following a successful demo to QA and Product/Business Teams. System testing will begin before the fully functional system is available. This will allow completed features to be verified, giving an early view of quality. This occurs after code complete. All features will be tested during the regression testing phase.
Objectives	To ensure that the system functions as expected. To discover defects that are properties of the entire system rather than its individual components.
Environment
Stage Entry Criteria	Test planning is in progress and has been reviewed appropriately. Specified unit testing is complete. New functionality has been demonstrated to the QA and Product/Business teams.
Stage Exit Criteria	The goals of the project shall have been met. All Blocker and Critical defects introduced as a result of new functionality should be fixed or targeted for resolution early in the regression phase (triaged and agreed upon by Prod, Development and QA).
Tools
Deliverables	Test cases Defect reports SIT/Feature test results
Schedule
Responsibilities	Creation of test requirements
Review and sign-off test requirements
Creation of test scripts
Review and sign-off test scripts
Maintenance of test results
Creation of Test Summary Report
Review and sign off system Test Summary Report

Regression Testing

Attribute	Description
Approach	Running prioritized tests from the regression test suite will ensure existing functionality continues to work as expected following the implementation of new functionality. The extent and scope of regression will be determined by the completion date of the system test phase, although some testing may run in parallel. Test cases will be prioritized by QA, Product and Development teams dependent on business priority and perceived risk. This occurs after code freeze.
Objectives	To ensure that existing functionality has not been affected by changes.
Test Types	This phase will cover existing functionality that has not been tested in the System/Feature Test phase.
Environment
Stage Entry Criteria	Regression test planning is complete and has been reviewed appropriately. System/Feature Testing is near to completion and the exit criteria have been met.
Stage Exit Criteria	The following are required before formal phase exit can occur: All Blocker and Critical defects must be fixed or triaged and waived by the Product/Business Team following discussion with the Quality and Dev Managers.
Tools
Deliverables	Test scripts Defect reports Regression test results
Schedule
Responsibilities

Installation and Rollback Testing

Attribute	Description
Approach	This test phase will test the installation process and ensure the rollback procedure is reliable. A small subset of functional tests will be scheduled to prove the install/configuration of the systems.
Objectives	To ensure that the installation and rollback process is documented, accurate and repeatable.
Environment
Stage Entry Criteria	New system functionality has been fully tested. Specified regression tests have been completed. System installation and rollback instructions have been formally reviewed and signed off by FNFG QA Team.
Stage Exit Criteria	Fully signed off installation instructions have been successfully executed. A post upgrade rollback has been successfully completed.
Deliverables	Proven installation and rollback procedure with accompanying documentation
Test team
Reviews	FNFG QA Manager and Release Manager
Responsibilities	Provide installation instructions
Create rollback plan
Sign-off test results and rollback plan

Client/UAT Testing

Attribute	Description
Objectives	To ensure that users/clients can verify the new functionality in the release. Also to determine whether to accept the software product, system rollout or an upgrade. To ensure system meets a set up previously agreed upon acceptance criteria.
Environment
Stage Entry Criteria	New system functionality has been fully tested. Specified regression tests have been completed.
Stage Exit Criteria	Client has completed and passed all specified tests, unless agreed otherwise by the product manager.
Deliverables	UAT results, Test Completion Certificate
Test team	Business/Prod team(s)
Reviews	FNFG QA Manager, Product manager
Responsibilities	Provide client test plan
Provide environment
Sign-off test results and rollback plan

Non-Functional Testing

Data Validation

Attribute	Description
Objectives	To ensure that all required fields are delivered and validated.
Environment
Stage Entry Criteria	Data sources have been identified.
Stage Exit Criteria	All data fields have been identified and checked for validity.
Deliverables	Defect reports Data Quality Test Results
Schedule	(Concurrent with System and Regression testing.)
Responsibilities	Defect reports
Create Data Quality Test Report.
Review and sign off Data Quality Test Results.

Performance Testing

Attribute	Description
Objectives	To evaluate compliance of the system with specified performance requirements or KPI’s. To ensure that the system can operate at the predicted business volumes.
Environment
Stage Entry Criteria	There are no known defects that will reduce the validity of the testing or limit its scope.
Stage Exit Criteria	All Blocker and Critical defects must be fixed or waived by the Product Team following discussion with the Quality and Dev Managers. All waived defects must be added to the Deficiency Management Plan. The system meets the KPIs defined.
Deliverables	Test scripts Defect reports Performance Test Results
Schedule
Responsibilities	New and updated defect reports
Create Performance Test Report.
Review and sign off Performance Test Results.

Documentation

Attribute	Description
Objectives	To ensure that the documentation is fit for purpose.
Environment	Staging environment
Stage Entry Criteria	Documentation completed.
Stage Exit Criteria	All errors have been fixed or waived by Product management
Deliverables	Documentation review reports
Schedule
Responsibilities	Review reports

Operations Acceptance Testing (OAT)

Attribute	Description
Objectives	To confirm alerting functionality, resiliency and performance in an Operational Environment.
Environment
Stage Entry Criteria
Stage Exit Criteria
Deliverables	OAT Test Report
Schedule
Responsibilities	Create OAT Test Report.
Organize and chair go/no go meetings

UAT (User Acceptance Testing)

Attribute	Description
Approach	The UAT phase designates the time window that follows the ex-QA date of the product or project delivery phase and is after the Fitness for Launch (FFL) review. During this phase, the product or project is made available on the production environment to potential users. A select group of business users will be given access to the product and requested to give feedback after a certain period.
Objectives	To test the delivery, and to gain the acceptance from Business/Product teams.
Environment
Stage Entry Criteria	1. All Critical defects have been Closed.
2. The QA gate has been completed
Stage Exit Criteria	Customer feedback is reviewed by product owners and the product is declared fit for revenue generation.
Deliverables	UAT Test Results
Schedule
Responsibilities	Identify suitable business users
Perform Smoke tests on UAT env
UAT Test Results

Test Environments

Environment Owners

Configuration and Integration Owner (Quality Control Manager) is responsible for ensuring that changes to environments are logged and system configuration is as close to the production environment as practically possible. Environments configuration should be tracked and documented.

Environmental Variances

All QA and User Acceptance environments should be configured as closely as possible to Production wherever possible. All differences should be documented and communicated to the stakeholders.

Reporting

Quality Reports

Weekly Quality Updates will provide a more comprehensive and consolidated view of QA progress and will also provide detailed information on the quantity and severity of defects raised.

Any showstoppers previously raised in past reports that were fixed over the current reporting period will be noted.

The Test Summary Report or Dashboard will be distributed on completion of the Feature/System Integration and Regression phases. This report will summarize coverage against the areas defined in the Test Plan. The Performance Test Report will summarize system performance against those tests defined in the Performance Test Scope (if applicable).

Defect reports

All defects found during System testing of the components will be logged by the appropriate teams. Defect reports will be available to FNFG QA management. Reports will be prioritised and assigned to a release during the defect triage meetings.

The frequency of defect triage meetings will be determined once the Quality Manager has a view of the code quality. Daily meetings will be held if this is deemed appropriate and meetings will be at least weekly.

Weekly QA Meetings

All members of the QA Teams will meet at least once per week to discuss QA progress and issues.

Weekly Project Meetings

On a weekly basis, the Team will meet to discuss weekly status. This meeting will review project progress and issues, and make appropriate priority calls if required.

Go Live Criteria

The following criteria will be fulfilled prior to delivery of the Project/Release into production:

Functional Sign Off

Formal sign off on functionality by the Product/Business Team(s).

Test Execution & Defect Review

All specified test cases have been executed and results recorded.

All Critical defects have been addressed. All Major defects have been addressed or waived/differed by the Product/Business Team(s).

All Test Reports have been distributed, reviewed and approved.

Non Functional Sign Off

Formal sign-off on non functional testing (if any) by the Product/Business team.

All applicable application owners have submitted a Test Completion Certificate to the Release Manager and Quality Control Manager.

Risks and Deficiency Management

Any outstanding defects/issues are reviewed and approved by the Product/Business, Dev and QA Teams.

Risks and Issues Log has been updated, reviewed and approved by the Product/Business Team(s).

Documentation

All documentation has been received and reviewed by the appropriate stakeholders.

Installation and Rollback

Installation/Configuration and rollback tests have been successfully performed on the final release candidate.

The Install and Rollback Guide have been reviewed and signed off.

This may not be applicable for all projects.

Appendix 1 - Staff Requirements

QA Team

The expected size of the QA team is as follows:

QA Manager

TBD

Manual QA Resources

TBD

Automation QA resources

TBD

The team size is expected to change depending on scope and/or other projects.

End of document